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ABSTRACT 



A smart card comprises a microcontroller, a memory unit, a 
storage unit, and a communications unit. The smart card may 
be connected to a terminal, which is in turn may be con- 
nected to a host computer and/or a network. The smart card 
is configured to initiate communications with the terminal, 
which enables the smart card to control the terminal, host 
computer, or network and to access the resources connected 
to the terminal, host computer, or network. A communica- 
tions protocol defines the commands that the smart card can 
send and allows the smart card to communicate using 
asynchronous or logical asynchronous communication. 
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SMART CARD CONTROL OF TERMINAL AND 
NETWORK RESOURCES 

[0001] This application claims the benefit of the filing of 
U.S. Provisional Pat. App. No. 60/051,326, filed Jun. 30, 
1997. 

BACKGROUND OF THE INVENTION 

[0002] The invention relates to smart cards, and in par- 
ticular to smart card control of terminal and network 
resources. 

[0003] Smart cards are used for a variety of applications 
including electronic game cards, identification badges, and 
data storage media such as electronic books. The smart cards 
are typically encased in a tamper-resistant, plastic or metal 
housing about the size of a credit card and contain one or 
more embedded integrated circuit devices. Terminals, such 
as ID verification systems and electronic video games, etc., 
are available with one or more smart card interfaces that 
permit connection of the smart card to the terminal. 

[0004] . In traditional systems, the terminals or terminal 
device accesses the smart card through standard protocols, 
such as the ISO 7816 protocol. These protocols usually limit 
the smart cards to the role of "slave", while the terminal or 
terminal device acts as the "master". This means that the 
smart card cannot initiate any action or communication, but 
can only respond to specific commands from the terminal. A 
prior art terminal typically starts in the idle state (SJll), as^ 
shown in FIG. l.(The termihirtrTerrtfansmits a command to 
f-lhe smart card (ST12), and then waits for a response (ST13)f 
-After receiving the response from the smart card (ST14), the 
'terminal returns to the idle state (STll)rSimilarly, as shown 
in FIG. 2, a prior art smart card begins with the smart card 
waiting for a command from the terminal (ST21). Upon 
receiving the command from the terminal (ST22), the smart 
card proceeds to prepare an appropriate response (ST23), 
transmits the response to the terminal (ST24), and returns to 
the wait state (ST21) to await the next command. Under the 
above scheme, there is no provision for the smart card to 
access resources controlled by the terminal. 

SUMMARY OF THE INVENTION 

[0005] In general, in one aspect, the invention relates to a 
smart card system. The system has a terminal and a smart 
card that is connected to the terminal and configured to 
initiate communication with the terminal. The smart card 
communicates with the terminal using a communications 
protocol that enables asynchronous communications 
between the smart card and the terminal. For systems that do 
not support asynchronous communication, the communica- 
tions protocol also enables logical asynchronous communi- 
cations. The system further comprises means for establish- 
ing full-duplex or logical full-duplex communication 
between the smart card and the terminal. The terminal may 
be connected to a host computer which is in turn connected 
to a network. The smart card can access the resources 
connected to the terminal, the host computer, and the net- 
work. 

[0006] In general, in another aspect, the invention relates 
to a smart card that has a communications circuit and a 
microcontroller. The microcontroller is configured to initiate 
communication with a terminal to which the smart card is 



connected. The smart card also has a storage unit that stores 
programs that are executed by the microcontroller and a 
memory unit that temporarily stores the programs. The 
terminal may be connected to a host computer and a net- 
work, and the smart card may access the resources con- 
nected to the terminal, the host computer, and the network. 

[0007] In general, in another aspect, the invention relates 
to a method of operating a smart card^/The method com=7 

fpis^s~trarismitting a'command from the smart card to_-the_ 
^terminal, waiting for a response from the terminal, and j 

(receiving the response from the terminal. The smart .card 

^mitiates-communication^wim^th^terminal. A communica^, 
tions;protoc6l,7wnich may be configured to ;be~ISO_7816' 
compatible, allows _the smart card_to communicate" asyrP 

'chronouslylwith thelterrhinal,/or logically asynchronously 
with the terminal in cases where the actual asynchronous 
communication is not available. Additionally, the commu- 
nication may occur in full-duplex mode. If a response is not 
received within a predefined time period, the smart card 
re-transmits the command. The method also comprises 
requesting a list of available services from the terminal and 
selecting a command based on the list of services. 

[0008] In general, in another aspect, the invention relates 7 
fto a method of debugging a smart card. The_method includes 
executing a-diagnostic-portion - of a program stored on the 
smart card, receiving a result from the smart card, and 
comparing the result with an expected result. The method 
further includes displaying the result on Vterminal d ispla^ 

[0009] Advantages of the invention include at least the 
following: smart card control of terminal, host computer, 
and network resources; smart card-initiated communication 
with a terminal, host computer, and network; and asynchro- 
nous communication between a smart card and a terminal, 
host computer, and network. Other advantages will become 
apparent from the below description and the following 
claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0010] FIG. 1 is a state machine diagram of a prior art 
terminal. 

[0011] FIG. 2 is a state machine diagram of a prior art 
smart card. 

[0012] FIG. 3 is a block diagram of a smart card system. 

[0013] FIG. 4 is a state machine diagram of the smart card 
of the present invention. 

[0014] FIG. 5 is a state machine diagram of the terminal 
of the present invention. 

[0015] FIG. 6 is a block diagram of a smart card com- 
munications scheme. 

[0016] FIG. 7 illustrates a smart card communications 
protocol. 

[0017] FIG. 8 is another embodiment of the smart card 
system. 

[0018] FIG. 9 is a method of operating a smart card. 

[0019] FIG. 10 is another method of operating a smart 
card. 
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DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

[0020] Throughout the description and the drawings, ele- 
ments which are the same will be accorded the same 
reference numbers. 

[0021] Referring to FIG. 3, a smart card systems 30 has a 
smart card 31 connected to a terminal 32 which has terminal 
resources 33 available. The terminal resources 33 may be 
very minimal, such as an input/output port for connecting to 
a host computer, or the resources 33 could be more exten- 
sive, for example, a keyboard, monitor, modem, cash dis- 
penser, and other specialized resources. 

[0022] In some systems, the smart card 31 and the terminal 
32 operate independently of any other devices. This is 
exemplified by portable value checker products which allow 
a particular value in the smart card 31 to be displayed by the 
terminal, and portable Mondex transaction devices which 
allow two smart cards 31 to be connected to a single terminal 
32, and to transfer data between the two cards 31. 

[0023] In other systems, the terminal resources 33 connect 
the terminal 32 to a host computer 34, which has certain host 
computer resources 35 available. These resources could 
include a network connection, keyboard, monitor, hard disk, 
and other types of resources common to computers or 
specialized for a particular application. The smart card 31 
can send commands to, and receive responses from, the host 
computer 34 through the terminal 32, and vice-versa. 

[0024] The host computer 34 optionally can be connected 
to a network 36 if the host computer resources 35 include a 
network port. This allows the host computer 34 to gain 
access to network resources 37, which include other com- 
puters, printers, storage devices, and other potential 
resources, including for example resources available on the 
Internet. In such systems, the smart card 31 can be used as 
a tamper-resistant storage unit for network passwords, keys, 
certificates, electronic cash, and other information which the 
host computer 34 uses for network access, electronic com- 
merce, and other types of network applications. 

[0025] An advantage of the smart card 31 isjhat it is able ^ 
to initiate-communication with the terminal 32 and thereby/ 
become a "master"_while the terminal 32 acts as a "slave", 
as illustrated in FIG. 4 and FIG. 5. Referring to FIG. 4, 
communications is in an idle state in the smart card 31 while 
the smart card 31 is processing data or waiting for some 
event to occur (ST41)./When the smart card 31 heeds to/ 
communicate with the terminal 327 it transmits^ command' 
(e.g., a display data cbmmand), or a^message, or a packetpf 
infoFmation to~the-terminal-(ST42). After the transmission, 
the smart card 31 waits (ST43) until-it.receives a response^ 
(ST44)'from the-termmal-32-(e:g.,-an acknowledgement-of 
the command). Once the response has been received, the 
smart card 31 returns to the idle state (ST41) until the card 
needs to communicate with the terminal 32 again. Under 
such a scheme, the smart card 31 may initiate communica- 
tion with the terminal at any time. For example, if data or 
information from the terminal 32 which is needed by the 
smart card 31 to carry out a certain task is missing or 
incomplete, rather than remain in an idle state awaiting 
further data transfer, the smart card 31 can act proactively 
and request the missing information from the terminal 32. 

[0026] Referringjo FIG.75, terminal.32- waits iii T an idle 
istatejfpr a rorhmand from the smart card 31 (ST51). When 



a'jsommand is detected; ttie terminal 32 receives the com- 
fmand-and_prepares_an_appropriate_response (ST52 andj 
ST53). The terminal 32 then transmits the response to the 
smart card 31 (ST54) and returns to the idle state to await 
receipt of another command (ST51). 

[0027] In a similar way, the smart card 31 may access host 
computer resources 35 and network resources 37 by issuing, 
for example, a print command to a printer resource or a send 
network message command to a network messaging 
resource. 

[0028] In some cases, it may be desirable to add time-out 
features to the smart card 31 so that if a response is not 
received in the allotted time, the smart card 31 takes 
alternative actions, such as re-transmitting the command or 
transmitting a different command. 

[0029] It should be noted that the state machine diagrams 
of FIGS. 4 and 5 represent systems with only half -duplex 
communication between the smart card 31 and terminal 32. 
Alternative systems may, of course, be designed to support 
full-duplex communication between the smart card 31 and 
terminal 32. For example, referring to FIG. 6, full-duplex 
communication between the smart card 31 and the terminal 
32 may be implemented using two conventional RS-232 
serial ports in both the smart card 31 and terminal 32. Serial 
ports 61 and 62 of the smart card 31 transmit and receive 
data to and from serial ports 63 and 64 in the terminal 32, 
respectively. Because the transmissions in one direction are 
independent in time relative to the transmissions in the other 
direction, the smart card 31 and the terminal 32 may 
communicate with each other asynchronously. 

[0030] In contrast, systems that have only half-duplex 
physical channels are generally limited to synchronous 
communication and typically require synchronous commu- 
nication protocols, e.g., the ISO 7816 protocol. However, 
such a system may implement a special low level protocol 
which appears as an asynchronous protocol interface to the 
higher level protocols. This will allow the devices in the 
system to communicate with each other and with external 
devices using high level protocols which require asynchro- 
nous communications. For example, a "polling protocol" 
may be used with a smart card 31 and a terminal 32 that 
support the ISO 7816 half-duplex low level protocols. In the 
polling protocol, the terminal 32 has an obligation to send 
packets to the smart card 31 at the earliest possible oppor- 
tunity. In the case where there is no terminal data to be sent, 
a special class of instruction code may be sent to indicate to 
the smart card 31 that this is only a polling packet. If the 
smart card 31 is ready to send data to the terminal 32, it 
sends a response to the terminal 32 containing a byte which 
indicates the length of the data the smart card 32 is ready to 
send. The terminal 32 then responds with a special packet 
having a length which is equal to the length indicated by the 
smart card 31. This then allows the smart card 31 to send its 
data to the terminal 32, effectively allowing the smart card 
31 to initiate communication with the terminal 32. The 
polling may be repeated at the maximum rate that is sup- 
ported by the terminal 32. Such a low level protocol may be 
augmented by marking each message in each direction with 
a unique identifier, for example, a sequence number. This 
allows the responses in either direction to be deferred and 
sent later using the sequence number to correlate with the 
original messages. For example, if the terminal sent a 
message requiring a response, at the low level protocol the 
smart card could continue communicating other messages 
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back and forth. Then, when the desired response is ready, the 
smart card 31 marks the response with the identification 
number of Ihe initiating message. When the terminal 32 
receives the response, it correlates the response with the 
original message and returns the response value to the thread 
that initiated the message. Such a scheme also may permit 
the original thread to continue execution without waiting for 
the response, and allows the response to be passed back to 
the thread (or to another designated thread) using a callback 
mechanism. It will be appreciated that this logically presents 
what appears to be a full asynchronous interface to the 
higher level protocols. 

[0031] Asynchronous communication between the smart 
card 31 and the terminal 32 allows more complex systems to 
be designed. For example, conventional packet protocols 
exist which would allow packets to be initiated by both the 
smart card 31 and terminal 32, which may result in multiple 
packets that are in various states of processing occurring at 
the same time. This permits the use of high level features 
such as multi-threaded communications and callbacks. In 
short, FIG. 4 and FIG. 5 are illustrative of the simplest state 
machines that implement smart card initiated communica- 
tions, which is the key to this invention. It is well understood 
that other state machines for both half-duplex and full- 
duplex communications can be devised, as well as non-state 
based protocols, and are intended to fall within the scope of 
this invention if such communication protocols include card 
initiated communication. Since low level protocols based on 
this invention could allow asynchronous communication 
between the smart card 11 and the terminal 12, this can 
further enable high level communication protocols, such 
Remote Procedure Call and Remote Message Invocation, to 
be used. Such protocols can greatly enhance the value of the 
smart cards for many applications. In short, FIG. 4 and FIG. 
5 illustrate only the simplest systems that implement smart 
card-initiated communications. Other systems having both 
half-duplex and full-duplex communications may be 
devised that, so long as they include smart card-initiated 
communication, are within the scope of the invention. 

[0032] In another embodiment, a communications proto- 
col, shown generally at 70 in FIG. 7 and in more detail in 
TABLE 1, defines the commands that the smart card can 
initiate with respect to the terminal, host computer, or 
network. The communications protocol 70 uses ISO 7816 
escape commands with the existing ISO 7816 protocol to 
generate a new set of smart card-initiated commands. The 
use of the ISO 7816 escape commands allows the commu- 
nications protocol 70 to retain backwards compatibility with 
standard ISO 7816 commands. Each command in the com- 
munications protocol 70 is comprised of the following ISO 
7816 fields: a class (CLA) field 71, an instruction (INS) field 
72, a first parameter (PI) field 73, a second parameter (P2) 



field 74, and a data (Data) field 75. Not every field is 
required for every command and some fields may be either 
left empty or filled with a null value. The fields themselves 
are standard ISO 7816 fields well known to one having 
ordinary skill in the art and will not be described here. 

[0033] The commands of the communications protocol 70 
may be defined broadly such that not every terminal, host 
computer, network, or the resources connected thereto will 
have the service requested. When a particular service is not 
available, the communications protocol 70 includes an error 
message which may be sent back to the smart card to 
indicate that the requested service is not available. In one 
embodiment, the communications protocol 70 includes a 
query command so that the smart card can query the 
terminal, host computer, or network to determine which 
services are available. In addition, the communications 
protocol 70 may use a global naming convention (e.g., the 
Domain Name Service (DNS)) such that the smart card may 
specify a particular resource on a global basis. 

[0034] Referring to TABLE 1, the commands defined in 
the communications protocol 70 include the following: 
Display Request, Activate Input Scan, Request Data Length 
in Buffer, Request Data in Buffer, Activate Secure ID Entry, 
Query Resources, and Send Network Message. The Display 
Request command allows the smart card to display infor- 
mation on the terminal, host computer, or network display 
device. A~Javaiprogram:implementing-this:Command:usingj 
the standard-Java -Ca rd-l-.O s pecification" is: shown in AppeiP 
djx^ApThe Activate Input Scan command scans for user 
input. The Request Data Length in Buffer command, which 
may be executed at any time, determines the length of the 
data in the input buffer. The Request Data in Buffer com- 
mand reads the data entered in the terminal, host computer, 
or network input buffer. The Request a Secure ID Entry 
command requests identification information such as a user- 
name, password, or biometrics information such as a thumb- 
print or voiceprint. The "Query Resources-commandf as 1 
/indicated above, queries the terminal, host computer, or) 
ijietwork forjivailable services and resources. This command 
may also be used to"aeterrhine~ other information such as 
available user input devices, secure ID devices, network 
connectivity, data files, database availability, and other types 
of services were resources. The Send Network Message 
command sends a message to a network computer which is 
identified by the standard DNS node ID convention. This 
command is-sent fjom4he-smart card to'the2holsCcomp5ter7 
wh ich must either recelvefandlexe^te thisT^coSm and _or 
creturn-an:erro1rn^pOT^ the network 

computer identified is the host computer, then the command 
is executed locally. Otherwise, the host computer routes the 
command through the network to the identified network 
computer. 



TABLE 1 



Communications protocol: Mapping To ISO 7816 Escape Commands 
Command Type CLA INS PI P2 Data Response 



Display Request 

Activate Input Scan 

Request Data Length In 
Buffer 

Request Data in Buffer 



DO E0 Fm Lc Disp Data 90 00 (OK) 
6F 00 (Error) 

DO El 00 00 None 



E2 00 00 



E3 00 Ln 



None 



None 



90 00 (OK) 
6F 00 (Error) 
Length + 90 00 (OK) 
6F 00 (Error) 
InputData + 90 00 (OK) 
6F 00 (Error) 
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TABLE 1 -continued 



Communications protocol: Mapping To ISO 7816 Escape Commands 
Command Type CLA INS PI P2 Data Response 



Activate Secure ID Entry DO E4 00 00 None Length + IDData + 90 00 (OK) 

6F 00 (Error) 

Query terminal Resources DO E5 Rs 00 None Length + ResData + 90 00 (OK) 

6F 00 (Error) 

Send Network Message DO E4 Ld Lm ID + Msg Length + Response + 90 00 (OK) 

6F 00 (Error) 



[0035] The communications protocol 70 may, of course, 
be expanded as required to support other services. Further- 
more, for systems that use full-duplex communication 
between the smart card and the terminal and do not require 
ISO 7816 compatibility, standard asynchronous callback 
mechanisms can be added to the protocol to expand func- 
tionality and improve performance greatly. For example, 
instead of sending a network message and waiting for a 
response, the smart card can continue normal processing. 
Once the response has been prepared by the DNS node that 
received the message, an asynchronous response message 
can be sent to the smart card. Other half-duplex and full- 
duplex communications protocols can be devised readily 
and are intended to fall within the scope of this invention if 
such communications protocols include card initiated com- 
munication. For example, a logical full-duplex scheme may 
be devised for systems that do not have actual full-duplex. 

[0036] Referring to FIG. 8, another embodiment of a 
smart card system 80 comprises a smart card 81 connected 
to a smart card terminal 32. The smart card 81 has an 
embedded microcontroller 82, memory unit 83, and storage 
unit 84, all of which are interconnected. The microcontroller 
82 executes smart card software and programs, carries out 
terminal instructions, and generally manages the flow of 
data to and from the smart card 81. In some embodiments, 
the microcontroller 82 may include a microprocessor (e.g., 
a 68HC05), a programmable array logic (PAL), an applica- 
tion-specific integrated circuit (ASIC), and/or other inte- 
grated circuit devices. The memory unit 83, which may 
include a random-access-memory (RAM), temporarily 
stores software and data used by the microcontroller 82 
during program execution. The storage unit 84, which may 
include a read-only memory (ROM), stores the basic pro- 
gram codes and data that are needed to configure and operate 
the smart card 31. New or updated codes and data may be 
downloaded or programmed into the smart card 81 from 
time to time to upgrade the smart card 81. The smart card 81 
also has a communications unit 85 that is connected to the 
"microcontroller 82 and allows the microcontroller 82 to 
transfer data to and from the terminal 32 and other external 
devices. Although shown as separate blocks, the microcon- 
troller 82, memory unit 83, storage unit 84, and communi- 
cations unit 85 may be combined into a single integrated 
circuit device or an otherwise reduced or expanded number 
of separate IC devices. 

[0037] The smart card 81 is^connectedjo the_ terminal 32 
bya smart-card'inferface 86 which facilitates commuhica-^ 
(tion between the smart card 81 and the terminal 32. Thej 
/"interface 86 typically includes a smart card reader or reader/I 
'-writer and a .power supply, such.as a battery, (not shown) that 
provides power to the smart card 81. In some embodiments, 
the interface 86 physically engages the smart card 81. In 
other embodiments, however, the interface 86 may use 



inductive, capacitive, or optical coupling, or the interface 86 
may use radio frequency signals to connect the smart card 81 
to the terminal 32. 

[0038] In operation, the smart card 81 is able to access and 
control the terminal 32 and terminal resources 33 by initi- 
ating communication with the terminal 32 and terminal 
resources 33, contrary to conventional smart cards that only 
respond to received commands. Referring to FIG. 9, com- 
munication between the smart card 31 and the terminal 36 is 
established, for example, via an electronic handshake or 
series of handshakes (ST91). The smart card 81 than 
requests a list of available services from the terminal 32 
(ST92). The list of services may vary depending on the type 
of terminal 32 (e.g., a video game, security system, etc.) and 
terminal resources 33. Once the list of available services or 
commands is received from the terminal 32 (ST93), the 
smart card 81 sends a command to the terminal 32 based on 
the services that are available (ST94). The smart card 81 
then checks to see if a response to the command has been 
received from the terminal 32 (ST95). If a response has been 
received, the smart card 81 encrypts (ST97) and stores 
(ST98) any data received from the terminal 32, and prepares 
itself to send another command to the terminal 32 (ST94). If 
not, the smart card 81 checks to see if a predefined time 
period has expired or timed out (ST96). if the predefined 
time period has expired, then the smart card 81 re-transmits 
the command to the terminal 32 (ST94). If the predefined 
time period has not expired, the smart card 81 checks again 
to see if the response has been received from the terminal 32. 

[0039] The smart cards described above facilitate a wide 
range of new and innovative smart card applications here- 
tofore unrealizable with conventional smart card architec- 
tures. Three such applications are disclosed below. 

[0040]_ -Smart card programs are typically very_difEcultJo 
("develop and debug due to the lackof visibility into the cards ] 
"necessitated by ~the strict security requirements of most V 
smart card applications. The ability of the smart card to drive / 
(theTerminal allows one having ordinary skill in the art to / 
(develop debugging applications that are resident on the cardj 
and program tesrharnesses to exefcisedifficulrto' reach 
sections of smart card code. Such applications can make use 
of a terminal display to provide internal state and runtime 
trace information to assist in debugging card resident appli- 
cations. Referring to FIG. 10, one such application begins 
with executing a debugging routine (ST101), for example, a 
memory test routine. After running the routine, the smart 
card outputs a result (ST102), such as, e.g., the number of 
rows and columns in the memory unit that passed the test. 
The results are compared with a known or predefined 
number of good rows and columns (ST103) and the results 
are displayed on the terminal display (ST104). In some 
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embodiments, the user may use a terminal input device to 
select different sections of the smart card's program to 
execute. 

[0041] Network games traditionally have suffered from a 
lack of security, which allows devious players to manipulate 
stored data to enhance game attributes to the detriment of 
other players. This can result in general dissatisfaction with 
the game itself. The solution employed in some cases is to 
require all players to access a secure host computer which 
stores the gaming files; however, this slows down the host 
computer and limits the number of simultaneous players per 
game. With a smart card that is able to interact fully with the 
user and the network, a game may be stored and executed 
entirely on the smart card. Such a game benefits from the 
secure environment provided by the smart card and does not 
require a secure host. This removes the limit on the number 
of simultaneous players. Also, each player may interact 
directly with other players and be confident that the gaming 
information stored on the opponent's smart card is free from 
tampering. 

[0042] Solitaire games which reward high scores also are 
subject to such tampering by devious players, which has 
discouraged the deployment of such games. However, with 
the game and data files, including the prize validation 
information, stored securely and executed in a smart card, 
these solitaire games can become more viable with dishonest 
play prevented and honest levels of achievement appropri- 
ately rewarded. 

[0043] It is to be understood that the embodiments 
described above are merely illustrative and that other 
arrangements can be devised by one of ordinary skill in the 
art at the time the invention was made without departing 
from the scope of the invention. 

What is claimed is: 

1. A smart card system, comprising: 

a terminal; and 

a smart card connected to the terminal and configured to 
initiate communication with the terminal. 

2. The smart card system of claim 1, further comprising 
a communications protocol that enables asynchronous com- 
munications between the smart card and the terminal. 

3. The smart card system of claim 2, further comprising 
a communications protocol that enables logical asynchro- 
nous communication between the smart card and the termi- 
nal. 

4. The smart card system of claim 1, wherein the smart 
card accesses terminal resources connected to the terminal. 

5. The smart card system of claim 1, wherein the terminal 
is connected to a host computer. 

6. The smart card system of claim 5, wherein the smart 
card accesses host computer resources connected to the host 
computer. 

7. The smart card system of claim 1, wherein the terminal 
is connected to a network. 

8. The smart card system of claim 7, wherein the smart 
card accesses network resources connected to the network. 

9. The smart card system of claim 1, further comprising 
a means for establishing communication between the smart 
card and the terminal. 

10. The smart card system of claim 9, wherein the means 
for establishing communication includes means for estab- 
lishing full-duplex communication. 



11. A smart card, comprising; 
a communications circuit; and 

a microcontroller connected to the communications cir- 
cuit and configured to initiate communication with a 
terminal to which the smart card is connected. 

12. The smart card of claim 1, further comprising a 
storage unit having a program stored therein. 

13. The smart card of claim 12, wherein the microcon- 
troller executes the program stored in the storage unit. 

14. The smart card of claim 13, further comprising a 
memory unit, wherein the microcontroller temporarily stores 
the program in the memory unit. 

15. The smart card of claim 11, wherein the terminal has 
terminal resources connected thereto and the microcontrol- 
ler accesses the terminal resources. 

16. The smart card of claim 11, wherein the terminal is 
connected to a host computer. 

17. The smart card of claim 16, wherein the host computer 
has host computer resources connected thereto and the 
microcontroller accesses the host computer resources. 

18. The smart card of claim 11, wherein the terminal is 
connected to a network. 

19. The smart card of claim 18, wherein the network has 
network resources connected thereto and the microcontroller 
accesses the network resources. 

20. A method of operating a smart card, comprising; 

transmitting a command from the smart card to the 
terminal; 

waiting for a response from the terminal; and 

receiving the response from the terminal. 

21. The method of claim 20, wherein the smart card 
initiates communication with the terminal. 

22. The method of claim 20, further comprising a com- 
munications protocol that includes 

a class field, 

an instruction field, 

a first parameter field, 

a second parameter field, and 

a data field. 

23. The method of claim 22, wherein the communications 
protocol is ISO 7816 compatible. 

24. The method of claim 20, wherein transmitting the 
command and receiving the response occur asynchronously. 

25. The method of claim 20, wherein transmitting the 
command and receiving the response occur logically asyn- 
chronously. 

26. The method of claim 20, wherein transmitting the 
command and receiving the response occur in full-duplex. 

27. The method of claim 20, further comprising re- 
transmitting the command if no response is received from 
the terminal within a predefined time period. 

28. The method of claim 20, further comprising request- 
ing a list of available services from the terminal. 

29. The method of claim 28, wherein the command is 
selected from the list of available services. 

30. A method of debugging a smart card, comprising: 

executing a diagnostic portion of a program stored on the 
smart card; 

receiving a result from the smart card; and 

comparing the result to an expected result. 

31. The method of claim 30, further comprising display- 
ing the result on a display. 

***** 
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